Enterprise architects evaluate technologies currently used by an enterprise and technologies potentially used by the enterprise. Such an evaluation may produce an approved technology list that specifies which technologies offer the best value for the enterprise in terms of purchasing and maintaining technology. Despite the production of an approved technology list, a project manager may approve a proposed project that uses a technology that is not on the approved technology list. Implementing a technology that is an exception to the approved technology list may result in architectural impacts throughout the enterprise, far beyond the area of expertise for the approving project manager. Architectural impact is an effect created by a project on approved technology for an enterprise. For example, a project creates architectural and technology impacts by using a software application which requires a security patch to be compatible with an approved security system.
Enterprise architects also evaluate projects according to architectural guiding principles. All standard path projects are evaluated to determine architectural impacts security. As a part of a software lifecycle process methodology, enterprise architects initially review all projects to ensure that no projects deploy that cause disruption, increase costs, or drive technologies that create support and maintenance issues. After an initial review by the enterprise architects, if a project is compliant according to the enterprise architecture guiding principles, the enterprise architects will sign-off on the project architecture and recommend that an architecture review committee approve the project. If a project is not compliant with the enterprise architecture guiding principles, the enterprise architects will work with a project team to ensure project compliance is achieved and that the project aligns with the organization enterprise architecture. Once project compliance is achieved, the enterprise architects will sign-off on the project architecture and recommend that the architecture review committee approve the project.
Evaluating architectural impacts may be a lengthy and duplicative process. For example, employees in each of the numerous domains, or subdivisions, in the enterprise may hold their own meeting to evaluate architectural impacts. In these numerous meetings, the employees may evaluate architectural impacts in their own domain without any information about how the project may impact other domains in the enterprise. Alternatively, one large evaluation meeting between the directors for each domain in the enterprise would be unproductive because the directors may not have the detailed knowledge to properly evaluate architectural impacts. The significant time that would be required to develop such knowledge in a large meeting would constitute a waste of time for the many directors of domains not impacted by the project. In yet another alternative, enterprise architects may make project decisions based on architectural impacts. However, project managers would have to lobby to overturn project decisions made by enterprise architects because the enterprise architects often fail to take all project considerations into account. The above-described situations present unique problems that are not adequately addressed by existing enterprise infrastructure development systems.